The following port access will be necessary in order to run the Topcoder Arena: Outbound access to www.topcoder.com on port 5001.
HTTP Tunneling While running on your machine, the Topcoder Arena will need to create a direct socket connection to the Topcoder competition server. In order for this to function properly, your local networking environment must allow outbound TCP connections to www.topcoder.com on port 5001. Since port 5001 is a non-standard port, many firewalls will not allow this access. If you do not have control over allowing this access, your only option will be to run the Arena utilizing HTTP tunneling.
By selecting either the HTTP Tunneling option on the Arena login screen, all network traffic to and from the Topcoder competition server will be wrapped as if it were standard HTTP traffic on a standard port (port 80). This should resolve most firewall issues. However, you should only utilize the tunneling option if it is necessary since the performance of the Arena will be significantly slower while the tunneling option is being utilized. HTTP Tunnel A is faster than HTTP Tunnel B but may not work on all connections. We suggest you try them in order (Direct, Tunnel A, Tunnel B), or use the Autodetect button to automate this process.
In each room there is a place to chat. You can communicate with the others in the room by simply typing in the chat line at the bottom of the screen. There are a number of features to make chatting easier.
Next to the chat line, you will find a box populated with a “>>”. Clicking on this box will expand your chat options and present two dropdown lists. The first list represents the type of chat message, while the second contains a list of the handles of all coders currently in the room.
General Chat The most basic form of chat is the “General” chat, which will simply allow you to type in a message. A general chat message will be sent to all the coders currently in that room. The general chat message type is equivalent to simply typing a message in the chat line without the chat feature box expanded.
Reply To When the chat gets busy in a specific room, it can be helpful to address a specific person with a chat message. Using the “ReplyTo” feature in the expanded chat box will allow you to choose a handle to which the chat message will be directed. A “ReplyTo” chat message is analogous to typing “[handle]: this is the message” on the chat line. The advantage of this is that the recipient of the message will see your chat as a highlighted message, indicating that the message is intended for them. A “ReplyTo” message will be seen by all coders who are currently in the room.
Whisper A whisper is a message that will be displayed to the recipient only. Choosing a whisper message type is the same as typing “/whisper [handle] this is the message” in the chat line. “/msg” can also be used in place of “/whisper”. Whisper messages can also be used to communicate with coders who are in a different room than where you are. Keep in mind that any Topcoder administrators (the orange handles) will also see any messages that are whispered at any time.
Emoting On occasion, you may find it useful to convey an emotion in the chat area in the third person. Any time the string “/me” appears as the first part of a chat message, the “/me” will be replaced with your Topcoder handle and the message will appear to all users in italics. (i.e. “/me is very happy”)
Searching for a Member Using the “Search” feature under the “Main Menu” will allow you to enter a member’s handle in order to find out if they are currently logged into the Arena and if so what room they are in. If the member is in fact currently logged in, you will be given the option of moving directly to the room they are in - without it being necessary to use the menus to navigate.
You may also use “/find handle” to locate another member in the Arena. If you wish to locate the assigned room for a given competitor - regardless of whether they are actually in that room, you have the option to use “/room handle” for information on that competitors assigned competition room.
Who is in the Arena now? The “Active Users” menu option under the “Main Menu” will provide you with a list of all Topcoder members who are currently logged in to the Arena. You may sort the list by either Topcoder handle or by rating by clicking on the column headings. In addition, by right clicking on any of the handles in this list you will have the option to either perform a search for that member or retrieve information for that member.
After each match, you can find comprehensive statistics about almost all aspects of the match on Topcoder’s website. This includes both summary information regarding success rate on each of the problems all the way down to viewing the code submissions of each competitor and the arguments that caused any submission to fail a system test. In order to view most of the statistical information on the website, you will need to log in to the site with your Topcoder handle and password. When the statistics have been compiled by our servers and are ready to be viewed (about 15-20 minutes after the system tests are complete), Topcoder will announce the availability of the statistics via an administrative broadcast message. “Statistics / Round Overview” in the left side navigation area of the Topcoder website will take you to the top level of the statistics for the most recent match. Clicking on the “[*]” symbol next to any entry will drill into the statistics for the given entry.
Many Topcoder participants find it useful to create code libraries for situations that commonly arise in Topcoder competitions. Doing such is perfectly legal - as long as the code used has been entirely authored by you. Use of any code other than that which has been authored by you is cheating (and you know how we feel about cheating). Keep in mind, however, that onsite rounds of Topcoder advancements tournaments are handled differently. On-site finalists of Topcoder advancement tournaments are not allowed to bring anything “on stage” - including code libraries.
Pasting large libraries of code into each submission with the intent of only using a small percentage (if any) is against the Excessive / Extra Code Rule.
The Topcoder Arena supports a “plug-in” architecture that allows additional functionality to be built in. While the functionality provided by these plug-ins is not initially available to you, you may freely install and configure any of the available plug-ins. Most plug-ins are designed to create a more efficient and effective competition environment. There are plug-ins available for feature-rich code editing, automatic example checking, external editor integration, auto code generation, and more. For a list of available plug-ins and instructions on how to install and use them, check here.
Here are a few answers to our most common questions
There absolutely is!
After each rated event, a practice room will be added to the Arena that contains the problem set that was used in that rated event. This gives the event participants a chance to identify their errors or fine-tune their solutions, and it gives others a chance to get a feel for the types of problems that are used in a rated event. Although the practice rooms behave a bit differently than an actual rated event, utilizing the practice rooms is the best way for a non-rated member to become familiar with the most important part of the Topcoder Arena. The practice rooms are labeled based on the match and division in which they were used as actual problems.
It is highly recommend that all new members visit the practice rooms prior to competing in an algorithm rated event. By visiting a practice room you will learn the Arena interface, the nature of the problems, and the expected structure of your solution. You will also get a chance to look at thousands of submissions in various languages from other competitors who have visited the practice rooms. At the very least, looking at some submissions from others who use your intended language will show you: 1) exactly how to structure your class, 2) the various input and output types that are specific to your language, and 3) how to import libraries in your language. Even though the submissions in the practice rooms are not necessarily correct, you do know that they have been successfully compiled.
Timing in the Practice Room
The practice room is designed to allow you to take your time and get a feel for the user interface. Once a problem is opened, you will have an unlimited amount of time to come up with a solution to the problem. However, the method of scoring is based on a total of 75 minutes - which is the amount of time that is given to complete a full set of problems during a rated event. The advantage of this is that the score that you receive upon submission of a solution will compare to the score that you would have received had you participated in that event. However, since there is no time limit in the practice area, if you exceed the 75 minutes, your score will bottom out at the lowest allowable score for that problem. During a rated event, the competition phases will proceed as such: coding phase, intermission, challenge phase, and finally the system-testing phase. In contrast, when in a practice room all of the functionality from the coding phase, the challenge phase, and the system-testing phase will be available all the time (see below for descriptions of each). There is no concept of changing phases in the practice rooms. In addition, the timer in the practice room will always show the phase as “Coding” and the remaining time as “00:00:00”. During a rated event, the timer will always count down to the end of each phase along with indicating the current phase.
Selecting a Problem
Once in a practice room, you will need to select a problem before you can begin coding. To select a problem, click on the “Select One” drop-down box. In the list you will see point values that correspond to the difficulty of the problem - the higher the value, the more difficult the problem will be. Problems with higher point values have the potential to yield higher points for a successful submission. Once a problem is selected, Topcoder’s server will begin keeping track of how long the problem has been open. The elapsed time between opening a problem and submitting a solution for that problem is the biggest factor in determining how many points are received upon submission of a solution. You may open more than one problem at a time - but keep in mind that the clock will be ticking for each problem, independent of one another. Once a problem is selected, the Coding Window will appear.
System Testing
After you’ve submitted one or more problems in a practice room, you have the option of running the system tests. During the system tests, various sets of valid input parameters are applied to your submission, with the output from your submission being compared against the expected output for each test case. If the expected output does not match the received output for one or more of the test cases, your submission will “fail” the system tests. Failing the system tests in a practice room will not mark your submission as failed, nor will it deduct any points from your final score (as it would during a rated event). The execution time for system tests in a practice room will vary depending on the number of submissions you have, the number of test cases there are, and the efficiency of your submissions. Just keep in mind that you may need to wait a minute or more for all tests to finish. The system test results will appear in a pop-up window when they are done - the results in the window will be for any/all problems that you have submitted in that room. The system testing option is only available in a practice room - it will not be available in a competition room during a rated event. In a rated event, the system tests will run automatically - following the challenge phase. You may run the system tests by choosing “Practice Options / Run System Tests” from within a practice room.
The Room Summary
The room summary window allows you to view information about other competitors and is also the interface for the challenge functionality. Check here for a detailed description of the Room Summary Window.
Challenging
When you are in a practice room, the phases behave as if the coding phase and the challenge phase are running simultaneously and perpetually. At any time, you may view the source code of any other competitors in a practice room - and you have the option to challenge any of the submissions. The challenge restrictions that are regularly in place during a rated event have been lifted for the practice rooms. Therefore, you may challenge regardless of your current point total and you may challenge any submission at any time, regardless of its status.
Here’s a link for a description of the Challenge Phase during a rated event.
Clearing Problems
Since this is a practice room, you are welcome to start over on any or all of the problems in any of the practice rooms. Under the “Practice Options” menu item that appears when in a practice room, you’ll see a “Clear All Problems” option along with a “Clear Problem(s)” option. The “clear all” will remove all of your submissions and history for all problems in that particular practice room. The “clear problem” option will allow you to specify a particular problem (or multiple problems) that should be cleared.
When are the Rated Events?
Topcoder holds two types of rated events, Single Round Matches(SRMs) and advancement tournaments(The Topcoder Open). The day and time of SRMs varies from week-to-week. See the event schedule on Topcoder’s web site for the dates and times of future SRMs. Please keep in mind that all times on Topcoder’s web site are communicated in either Eastern Standard Time (EST / GMT -5) or Eastern Daylight Time (EDT / GMT-4) depending on the time of the year. In addition, you may elect to receive a reminder email preceding each SRM. To do so, visit your email settings and make sure the switch next to “Data Science Newsletter” is turned on. By checking this option, you will also receive emails regarding upcoming Topcoder tournaments and events.
In addition to SRMs, Topcoder holds two advancement tournaments (the Topcoder Open and the Topcoder Collegiate Challenge) each year. Advancement tournaments are elimination tournaments and generally have a substantial prize purse involved. Each round of a tournament will affect the ratings of all participants, which is why they are also considered “rated events”. The details on each of these events are posted on Topcoder as they are finalized. You can also view the information and details of most past tournaments.
How does a Rated Event Differ from the Practice Room?
There are a number of differences - the biggest being that participating in a rated event will affect your Topcoder rating, whereas utilizing the practice rooms does not affect your rating. If you register for a rated event and proceed to open any of the problems during the coding phase, your rating will be affected following the match.
Additionally, a rated event is timed - whereas in a practice room you have unlimited time to submit solutions to a problem (and start over if you’d like). For example, if you attempt to submit a solution after the coding phase has ended, or a challenge after the challenge phase time has run out, the Topcoder servers will reject it.
In the practice rooms, you always have the ability to view the source code of other members who have submitted code in that room. In a rated event, you will not have the option of viewing the source code of other competitors until the start of the challenge phase.
During a rated event, you must always be cognizant of the amount of time that is remaining in the current phase of competition.
Division One versus Division Two
At Topcoder, there are two divisions of competition. The specific division that you are in is dependant only on your Topcoder rating. If your Topcoder rating is 1200 or above, you will be competing in Division One. Otherwise, you will be competing in Division Two - even if you are not rated. The problem set in Division One is harder than the Division Two problem set. Frequently, one problem from the Division One set will be shared in Division Two - generally as a higher point value problem. A coder will move into Division One immediately upon attaining a rating of 1200 or higher. Likewise, when a coder’s rating drops below 1200, they will be placed (and seeded) in Division Two. The rating calculations that are performed at the end of each match will only consider your comparative performance within the division that you competed in.
Topcoder has a policy against including extra content in a submission that is not part of the solution to the problem. This includes, but is not limited to the following:
unused macros
unused #define’s
unused typedef’s
automatically generated code
testing code
unused personal library code
comments not directly related to the solution
The following things are excluded from the rule (They are not considered unused):
Library import statements (#include, imports, using, Imports)
Comments identifying plugins used
Comments directly related to the solution (explaining algorithms, etc.)
In ALL cases, Topcoder will make the final decision as to whether or not a code submission has an excessive amount of unused content. If Topcoder determines that a submission violates this policy, the competitor will receive 20% of the point value of the problem for that submission. No challenges will be overturned or nullified as a result of a violation in this policy. We encourage any Topcoder competitor to notify us in the event that you feel that a code submission during a rated event violates this policy.
In an effort to help competitors determine how much extra content can be contained in a submission and still not violate this policy, we provide the following general guideline: You may have a maximum of 300 non-space characters that are considered extra content or a maximum of 30% of your submission be considered extra, whichever is greater.
At some point during your Topcoder adventures you will likely need to get a question answered by the administrators. During rated events, there are always administrators available to answer your questions. The best place to find a Topcoder administrator (identified by their bold, orange handles) is in the “Admin Lobby Room” - which can be found under the “Lobbies” menu option. Please keep in mind that all chat in the Admin Lobby Room is reserved for questions related to the current rated event that is taking place. You also may communicate with Topcoder administrators without leaving your assigned competition room. At any time while in the Topcoder Arena, prefacing a chat message with "admins: " will broadcast the chat message to the Admin Lobby Room, as well as the room that you are in. The Topcoder Administrators can reply directly to you without leaving the Admin Lobby Room. If you prefer a private correspondence with the Topcoder Administrators, you may whisper to an individual administrator by prefacing your chat message with "/msg ". This will allow you to ask a question of the administrators without others in your room being able to see the nature of the question. All administrators will see your whisper (as well as all whispered messages).
The point value of a submission is dependent upon the problem’s level of difficulty and the time it took to code a solution. The Topcoder server will calculate the time spent on a problem by counting the time between when the coder selects a problem and when a solution is submitted. Keep in mind that these times are captured when a problem request or problem submission actually gets to our server, so network latency may play a minor role in the competition process.
Total points awarded =
Where PT is the time spent coding a problem, TT is the total time allocated for coding all problems, and MP is the maximum points available for that problem.
For example: A coder spends 22.7 minutes working on the medium problem before submitting. Given the fact that the total coding round is one hour, and the maximum point value for the medium problem is 500, the coder’s awarded points for the submission will be:
500(.3 + .7602/(10*22.72+60^2))
or
293.95 points (point calculations are rounded to two decimal places)
In the event that you do not agree with some aspect of the results of a match, you have until 11:00 AM EST/EDT on the day following the match to notify Topcoder of your concerns. Please send an email to support@topcoder.com explaining in detail what you feel is inaccurate. We will investigate each appeal and we will determine what, if anything, to do about it.
You may get disconnected from the Internet for various reasons. If you get disconnected from Topcoder’s servers while you are in the Arena, simply log back in and move to your assigned competition room. You will not be penalized for logging out - however, the time will always be counting down from when you first opened the problem (or problem(s)). Once you reopen the problem that you were working on, the latest compiled or saved code should appear in the Coding Window. Remember to save your code often!
Cheating is taken seriously at Topcoder. There are a number of ways in which you could cheat, and have your account deactivated by Topcoder.
Collaborating in any way with anyone else (member or not) during a rated event is considered cheating. This includes discussing problem statements or solutions between the time that the coding phase begins and the time that the challenge phase ends.
Using multiple accounts to participate in a rated event is considered cheating.
Registering a new account for the purpose of resetting your rating is considered cheating.
Purposefully performing poorly during a rated event with the intention of artificially lowering your rating is considered very poor sportsmanship - and may result in account deactivation.
Modifying the Arena applet in any way is against the rules and may result in account deactivation. Attempting to digitally extract competitor’s code during the challenge phase is considered cheating.
Obviously, Topcoder cannot identify all malicious behavior (we try hard, though), so we do rely on each member’s sportsmanship and integrity.
The ability to quickly code solutions to a set of somewhat simple algorithmic problems does not completely define a “top” programmer. However, our attempt to make Topcoder tournaments as objective as possible has initially lead us in this direction. We continuously discuss ways in which we might introduce code elegance, style, reusability, and other less objectively ratable elements into our tournaments. We’d love to hear any suggestions on how this might be accomplished.
The coder. Our Terms of Use agreement specifies that the coder who submits any source code to Topcoder owns the code, but by submitting any source code the coder agrees to license to Topcoder the right to use and publish such code. You can read the complete Terms of Use agreement.
Each tournament round is an elimination round. Contestants survive to subsequent rounds by being the fastest to write working programs that accurately answer the challenge question(s). Ratings will then be adjusted by comparing the competitor’s record against the other members. The details of the rating formula can be found here.
Apparently, Sun has a problem with their font.properties file on the Linux platform that is causing errors with some fonts (Arial is one of them). The fix is to replace the font.properties file with the following: http://java.sun.com/j2se/1.3/font.properties
Java
Topcoder submissions typically consist of a single class definition. For each test, one instance of the class is constructed; then the method described in the problem is called with the test arguments. Therefore, your method must be public, and your class must be instantiable: public default constructor, no abstract methods, etc.
Each Java test is performed in a separate thread. The process is forcibly terminated after consuming 2 seconds of System time. At most 64 megabytes of memory may be mapped.
If your method does return a value, that is the only basis for judging correctness.
Microsoft® Visual C#® .NET or Microsoft® Visual Basic® .NET
Topcoder submissions typically consist of a single class definition. For each test, one instance of the class is constructed; then the method described in the problem is called with the test arguments. Therefore, your method must be public, and your class must be instantiable: public default constructor, no abstract methods, etc.
Each Microsoft® Visual C#® .NET or Microsoft® Visual Basic® .NET test is performed in a separate thread. The process is forcibly terminated after consuming 2 seconds of System time.
If your method does return a value, that is the only basis for judging correctness.
C++
Topcoder submissions typically consist of a single class definition. For each test, one instance of the class is constructed; then the method described in the problem is called with the test arguments. Therefore, your method must be public, and your class must be instantiable: public default constructor, no abstract methods, etc.
C++ submissions may also define other classes and global variables or functions. However, defining main() will prevent your submission from linking, and referring to library globals (stdout or cout for example) before your method is called is not guaranteed to work as expected. Each C++ test is performed in a separate process. The instance of your class used by the tester is not guaranteed to be destroyed. The process is forcibly terminated after consuming 2 seconds of CPU time. At most 64 megabytes of memory may be mapped. Stack space is limited to 8 megabytes (the Linux default). Most system calls are emulated or ignored. Note especially that fork() or use of threads (library or kernel) will fail, and use of temporary files is not permitted.
If your method does not return before the process exits (due to exceeding the time limit, an uncaught exception, segmentation fault, divide by zero, etc), it has failed the test.
If your method does return a value, that is the only basis for judging correctness. Anything printed to stdout or stderr is ignored, although you will see it when testing your own code. Output may even return an IO error, and takes extra time during testing; you are advised not to leave unnecessary IO in your final submission.
Java
We use 6 2-way 3.6 Ghz Pentium IV Xeon systems.
Microsoft® Visual C#® .NET or Microsoft® Visual Basic® .NET
We use 2 2-way 3.6 Ghz Pentium IV Xeon systems.
C++
We use 2 2-way 3.6 Ghz Pentium IV Xeon systems.
Java
Linux 2.4, Java 5.0 (build 1.5.0_03).
Microsoft® Visual C#® .NET or Microsoft® Visual Basic® .NET
Microsoft Windows 2000 5.00.2195 SP2, .NET Framework version 2.0.50727
C++
Linux 2.4.20-8smp, gcc 4.0.2 (Redhat 9), glibc-2.3.2, and libstdc+±3. pointers to appropriate docs for each http://gcc.gnu.org/onlinedocs/gcc-4.0.2/gcc/ http://www.gnu.org/software/libc/ http://gcc.gnu.org/onlinedocs/libstdc++/documentation.html
1
java - client - Xmx64m < main class >
You need to import “Imports Microsoft.VisualBasic”
Because we compile with optimization on, the compiler will sometimes rearrange and optimize functions in such a way that line numbers no longer match the original source code. We recommend you add Console.WriteLine() statements to help debug the problem if necessary.
The compiler is invoked as: g++ -Wall -W -O2 -s -pipe Additional info on gcc 3.1 http://gcc.gnu.org/bugs.html#updating
Only default libraries will be linked with your code. Math functions requiring libm on some platforms, eg cos(), are automatically linked if needed.
Integer types on our platform: char - 8 bits (signed) short - 16 bits int - 32 bits long - 32 bits long long - 64 bits long long is not merely a gcc extension, but part of ISO C99. If you test locally with a compiler other than gcc, the preprocessor may be useful for hiding the differences. For example:
1
2
3
4
5
#ifdef __GNUC__
#define int64 long long
#else /* MSVC, say */
#define int64 __int64
#endif
In this way, you can test the same code using 64 bit integers in our environment and on your system. The C++ standard libraries do not include support for arbitrary precision arithmetic.
All of the standard value types and container types should be present. Some extensions are also present, including most of those from SGI’s STL, such as rope, hashset, hashmap, tree, slist, etc.